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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



1 Scope 

The present document provides the procedure details and the information flows for support of Personal Network 
Management including the PN UE redirection and PN access control applications enabled by Personal Network 

Management (PNM). 

NOTE: This specification does not currently cover the stage 1 requirements for PNE Networks specified in 3GPP 
TS 22.259 [1]. 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

For a specific reference, subsequent revisions do not apply. 

For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 22.259: "Service requirements for Personal Network Management (PNM)". 

[2] 3GPP TS 23.002: "Network architecture". 

[3] 3GPP TS 23.218: "IP Multimedia (IM) Session Handling; IM call model". 

[4] 3GPP TS 23.228: "IP multimedia subsystem; Stage 2". 

[5] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[6] 3GPP TS 22.002: "Bearer Services Supported by a Pubhc Land Mobile Network (PLMN)". 
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[7] 3GPP TS 22.003: "Circuit Teleservices Supported by a Public Land Mobile Network (PLMN)". 

[8] 3GPP TS 23.078: "Customized Applications for Mobile network Enhanced Logic (CAMEL) 

Phase 4; Stage 2". 

[9] 3GPP TS 33.222: "Generic Authentication Architecture (GAA); Access to network application 

functions using Hypertext Transfer Protocol over Transport Layer Security (HTTPS)". 

[ 1 0] 3GPP TS 23 .0 1 8 : "Basic Call Handling; Technical realization" . 

[11] 3GPP TS 33.220: "Generic Authentication Architecture (GAA); Generic bootstrapping 

architecture". 

[12] 3GPP TS 23.090: "Unstructured Supplementary Service Data (USSD); Stage 2". 

[13] 3GPP TS 22.085: "Closed User Group (CUG) Supplementary Services; Stage 1". 

[14] 3GPP TS 23.085: "Closed User Group (CUG) supplementary service; Stage 2". 



3 Definitions and Abbreviations. 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 22.259 [1] 
subclauses 3.1 and 4.2.1 apply: 

Personal Network (PN) 

Personal Network Element (PNE) 

PN UE redirection 

PN access control 

PN-user 

default UE 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.002 [2] apply: 

Application Server (AS) 
For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.218 [3] 
subclause 3.1 apply: 

Initial filter criteria 
Initial Request 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.228 [4] 
subclause 3.1 apply: 

Public user identity 
Private user identity 
Proxy-CSCF (P-CSCF) 
Serving-CSCF (S-CSCF) 

For the purposes of the present document, the following terms and definitions given in 3GPP TR 21.905 [5] apply: 

User Equipment (UE) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 22.085 [13] apply: 

Incoming Access (lA) 
Outgoing Access (OA) 

For the purposes of the present document, the following terms and definitions apply: 
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PN UE name: A name selected by a PN-user for a PN UE of the PN-user"s PN and recorded together with other 
subscription data like the public/private user identity/identities by the operator in the HSS and the PNM AS by means of 
provisioning. A PN UE name (e.g., 'MeinSchatz') for a PN UE is unique within the PN-user"s PN. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply. 

CUG Closed User Group 

PN Personal Network 

PNE Personal Network Element 

PNM Personal Network Management 



PNIVI overview 



4.1 General 

Personal Network Management (PNM) is a home network-based application and provides the home network-based 
management of Personal Network (PN) consisting of multiple devices belonging to a single PN-user, as described in 
3GPP TS 22.259 [1]. These home network-based management functions cover the configuration of the PN-user"s PN 
such as PN-registration, PN-deregistration, PN-configuration, PN-deconfiguration and PN-query procedures, and the 
operation of the PN-user"s PN. Functionality enabled by the PNM comprises the PN UE redirection and the PN access 
control applications as described in 3GPP TS 22.259 [1]. In order to provide the PN UE redirection and the PN access 
control applications, the PNM is realized as an AS in the IM CN subsystem as described in 3GPP TS 23.002 [2] and as 
a CAMEL service in the CS domain as described in 3GPP TS 23.078 [4]. 



4.2 PN access control concepts 



The PN access control is one of the PNM applications specified in 3GPP TS 22.259 [1] that enables PN-users to 
exercise access control to restrict accesses to certain UE(s) of their PNs. The PN may consist of UEs which are only 
privately accessed, that is each UE may be accessed only by other UEs of the PN. The PN-User may additionally 
modify the access levels of each UE of the PN to be public or private. In this regard the PN behaves similar to a CUG as 
specified in 3GPP TS 22.085 [13] and 3GPP TS 23 085 [14], with Outgoing Access and whether Incoming Access is 
allowed for the PN UE is dependent on the PN access control list for that PN UE. 

In order to perform such PN access control the PN-users need to configure a PN access control list for each UE of the 
PN. The configuration can be done either in a static or a dynamic way. Besides other additional information, the PN 
access control list of a UE within a PN contains all identities (e.g., a SIP URI) which are permitted to be used to initiate 
sessions to that UE. In this document, the UE of a PN that is used by the PN-user to exercise access control is referred 
to controller UE, whereas the UE of the PN, over which an access control is enabled, is referred to controllee UE. The 
controller UE of a PN-user"s PN is assigned by provisioning and the controller UE can configure any UE of the PN as 
controllee UE. The PN access control list of the controllee UE is only configurable by the controller UE. 
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Access Control 



IMS Subscription 



Private User 
Identity 1 



Public User 
Identity a 



Public User 
Identity b 



UE1b 

CONTROLLED 
Service Profile 



PNMAS 



Access 
List 



Private User 
Identity 2 



Public User 
Identity c 

Public User 
Identity d 



UE1a I =t 

Configuration! 
CONTROLLER over Ut | 

Service Profile 



I Query-response 

Figure 4.2-1 : Relationship of various service profiles in PN access control 

An example of the service profiles configuration for PN access control is shown in the above figure 4.2-1. The arrows 
indicate the direction of control. Some of the aspects involved are: 

A PN-user"s PN consists of two UEs, i.e., UE la and UE lb, where UE lb is the controllee UE and UE la is the 
controller UE. 

The service profile of UE lb is referred to as the controllee UE Service Profile. 

The service profile of UE la is referred to as the controller UE Service Profile. 

The assignment of controller UE service profile is done during provisioning. 

Access control of UE lb by UE la is performed with the help of a SIP Application Server (AS), referred to as 
PNM AS. 

From UE la, the PN-user configures a PN access control list that contains details of PN access control regarding 
UE lb"s service profile. This configuration is done over the Ut interface. For example: this PN access control list 
can contain a list of UE identities that are allowed to initiate sessions with UE lb. 

The PNM AS executes the actual PN access control procedures. 

The PNM AS performs PN access control by utilizing the PN access control list. 

If inadequate information present in the access control list to enable PN access control, the PNM AS can query 
the controller UE about the information with how to precede the received initial request. 
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Procedures and information flows for PN 
configuration 



5.1 PN-registration 



5.1.1 



General 



The PN-registration is a procedure where the PN-user requests authorization to use PNM applications. As a result of a 
successful registration, the UE capabilities can be conveyed to the PNM AS. 

5.1 .2 PN-registration procedure in tine IM CN subsystem 



S-CSCF 

(Registrar) 



-1. Register — ► 



HSS 



PNM AS 



< — 2. Cx Query/Response— 

•* 3. Register— 

< 4. Subscribe- 



-5. Notify- 



6. Authorization 1 



7. Verify and enrol the 
public user identity 



Figure 5.1.2-1: Successful PN-registration procedure in the IIVI CN subsystem 

1. The Register information flow sent by a UE arrives at the S-CSCF/Registrar. The Register information flow 
contains the private user identity and the public user identity of the UE. 

2. The S-CSCF sends a Cx-Put/Cx-PuU containing the private user identity and public user identity to the HSS and 
the HSS returns the information flow (eg. the initial filter criteria) to the S-CSCF. 

3. Based on the initial filter criteria, the S-CSCF sends a Register information flow to the PNM AS. If the PNM AS 
specific data, for instance the PN UE name or the private user identity, which is associated with the initial filter 
criteria, is received from the HSS in Step 2, it is delivered to the PNM AS in the Register information flow. 

4. The PNM AS sends a Subscribe information flow to obtain the public user identity received in the Register 
information flow in Step 3. 

5. The S-CSCF sends a Notify information flow to the PNM AS containing the public user identities and the UE 
capabilities. If the S-CSCF assigned a GRUU for the UE during the registration, then the GRUU of the UE is 
delivered in the Notify information flow. 
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NOTE: At the same time as Steps 4) and 5) the AS can also contact the HSS using Sh to obtain the information. 
Where identical information is received from both sources, it is implementation specific how this is 
combined. 

6. Optionally, the PNM AS authorizes the PN-registration by querying the HSS. It is done by sending the private 
user identity to the HSS. The HSS checks the public user identity/identities tied to the private user identity and 
sends the public user identity /identities and the private user identity back to the PNM AS. 

7. The PNM AS then verifies the PN-registration by comparing the public user identity/identities and the PN UE 
name or with the other received from S-CSCF in the Step 3. As a result of a successful verification, the PNM AS 
enrols the public user identity and the PN UE name or as registered in the data base. 



5.1 .3 PN-registration procedure in tine CS domain 



MSCA^LR 



HSS 



1 . Receive a Location 
Update Request 



2.MAP UPDATE LOCATION 



3.MAP-INSERT-SUBSCRIBER-DATA 



gsmSCF 
(CAMEL Service for PNM) 



4.MAP NOTE MM EVENT 



5. Setup the UE registration 
satus in the PN 



6. UE status 



PNM AS 



Figure 5.1.3-1 : Successful PN-registration in the CS domain 

1 . The VLR receives a location update request from a UE. 

2. The VLR sends the MAP_UPDATE_LOCATION message to the HSS to request the subscription info of the 
UE. 

3. The HSS sends the MAP_INSERT_SUBSCRIBER_DATA message back to update the VLR with the PNM 
subscriber data. 

4. The VLR changes the status of the UE to "attached "and sends the MAP_NOTE_MM_EVENT message to the 
gsmSCF (CAMEL service for PNM) to report the mobile event. 

NOTE: To support the mobility management event, the CAMEL Phase 3 or later is required. 

5. The gsmSCF setups the UE registration status in the PN to "registered". 

6. The gsmSCF will send the UE status to the PNM AS. 

NOTE: The interface between the gsmSCF and the PNM AS is unspecified. 
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5.2 PN-deregistration 

5.2.1 General 

Information shall be offered to the user by sending the status if the de-registered UE is the only default UE of the PN. 

Figure 5.2.2-1 provides the procedure in the IM CN subsystem to inform the PN-user about De-registration of the only 
default UE in the PN. 

Figure 5.2.3-1 provides the procedure in the CS domain to inform the PN-user about De-registration of the only default 
UE in the PN. 

5.2.2 PN-deregistration procedure in tine IM CN subsystem 



S-CSCF 
(Registrar) 



HSS 



1 . Register 



2. De-Register 



5. Unsubscribe 



6. Cx Put/Response 



3. Authorization 



7. Status 



PNMAS 



4. Verify and 

de-register 

the public 

user identity 



Figure 5.2.2-1 : Successful PN-deregistration procedure in thie IIU! CN subsystem 

1. To de-register, the UE sends a new Register information flow with an expiration value of zero seconds. The 
Register information flow contains the private user identity and the public user identity of the UE. 

2. Based on the initial filter criteria, the S-CSCF sends Register information flow with an expiration value of zero 
seconds to the PNM AS. 

3. Optionally, the PNM AS authorizes the PN-registration by querying the HSS. It is done by sending the private 
user identity to the HSS. The HSS checks the public user identity /identities tied to the private user identity and 
sends it back to the PNM AS. 

4. The PNM AS then verifies the PN-registration by comparing the public user identity/identities with the other 
received from S-CSCF in the Step 2. As a result of a successful verification, the PNM AS enrols the public user 
identity as de-registered in the data base and removes the stored configuration setting related to this specific 
public user identity. 

5. The PNM AS sends an Unsubscribe information flow to unsubscribe to the service subscription notification of 
the public user identity. 

6. The S-CSCF sends a Cx-Put/Cx-Pull containing the private user identity, public user identity and clear/keep S- 
CSCF name to the HSS base on operator choice and the HSS returns response to the S-CSCF. 
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7. If the UE ties to this specific pubHc user identity registered as the only default UE, then the PNM AS sends the 
status to these UEs of the PN to inform this change. 

5.2.3 PN-deregistration procedure in the CS domain 

The PN-deregistration in the CS domain relies on the notification procedure of mobility management event and is 
accomplished by a notification with the event type of IMSI detach. 



MSCA'LR 



HSS 



gsmSCF 
(PNM Application) 



-1.MAP NOTE MM EVENT- 



-4. .USSD Notify- 



2. Set the UE 

registration status 

in the PN 



-3.USSD Notify- 



-5. .USSD Notify- 



UE 



Figure 5.2.3-1 : Procedure to inform the PN-user about the PN-deregistration of the default UE 

1 . After IMSI detach procedure, the VLR sends the MAP_NOTE_MM_EVENT message to the gsmSCF (CAMEL 
service for PNM) to report the mobile event. 

2. The gsmSCF sets up the PN UE registration status in the PN to "Deregistered". 

3. The gsmSCF checks whether the PN UE was the only default UE in the PN or not. If it was the only default UE 
in the PN, the gsmSCF generates the USSD Notify message to the HSS. 

4-5. The HSS forwards this message to the PN UE via MSC/VLR according to 3GPP TS 23.090 [12]. 
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5.3 PN-configuration 

5.3.1 General 

The PN-configuration procedures enable the PN-user to configure UEs as the defauh UE for terminating requests 
addressed to any UE belonging to the same FN and to configure the PN access control list. The PN-configuration can be 
done in three levels in IM CN subsystem and two levels in CS domain. They are a global level for all services supported 
by the UE capabilities and subscriptions, a per service basis for selected services supported by the UE capabilities and 
subscriptions, and a per service component basis for the different media of a supported service for the UE. 

The following subclause describes the PN-configuration procedures in the IM CN subsystem. The signalling flow in 
figure 5.3.2-1 describes the information flow exchange between UE and NAF/PNM AS when the UE performs the PN- 
configuration. 

5.3.2 PN-configuration procedure in tine IM CN subsystem 



UE 



HSS 



-1. PN-configuration request- 



NAF/PNM AS 



2. Authentication 
and Authorization 



3. Service Subscription 

Query Request 

4. Service Subscription 
Query Response 



5. CheckUE's 

Capability 
Subscription 



6. Service Subscription 
Subscribe Request 

7. Service Subscription 
Subscribe Response 



8. Store tlie 

Configuration 

Setting 



-9. PN-configuration response- 



Figure 5.3.2-1 : Successful PN-configuration procedure in the IIVI CN subsystem 

The signalling flow in figure 5.3.2-1 describes the signal flow between UE and NAF/PNM AS when the UE wants to 
configure the PN. The procedure shall only take place after a successful bootstrapping procedure (as described in 
3GPP TS 33.220 [11]) in which case the bootstrapped security association has been established before Step 1. 

1 . UE sends a PN-configuration request to the NAF/PNM AS informing the PNM AS about its desirable settings 
for the PN UE redirection applications and/or the PN access control list. The PN-configuration request contains 
the public user identity/identities of the UE, and the PN UE names of the UEs to be configured. The relevant 
parameters for executing the PN UE redirection application (e.g configuration level and the priority value) may 
be included. The controller UE and controllee UE, and the PN access control list including either the public user 
identities (if reachable in the IM CN subsystem) and/or the directory number (if reachable in the CS domain) 
may be included. 
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Editor's note: Whether routing information is needed is FFS. 

2. Upon receiving this Configuration request message, the NAF/PNM AS authenticates the PN-configuration 
request according to the 3GPP TS 33.222 [9]. After a successful authentication, the NAF inserts the private user 
identity of the UE and forwards the requestto the PNM AS. The PNM AS authorizes the Configuration request 
message by comparing the pubHc user identity and the PN UE name with those ones that are registered in the PN 
by means of the PN -registration procedure. 

3. The NAF/PNM AS sends a Service Subscription Query request to the HSS in order to obtain the service 
subscription tied to the pubHc user identity received in the PN-configuration request. 

4. The HSS sends a Service Subscription Query response back to the NAF/PNM AS with the service subscription 
tied to the public user identity. 

5. Upon receiving the Service Subscription Query response, the NAF/PNM AS verifies the UE capability and the 
service subscription of the public user identity. 

6. The NAF/PNM AS sends the Service Subscription Subscribe request to the HSS. 

7. The HSS sends the Service Subscription Subscribe Response to the NAF/PNM AS. 

8. The NAF/PNM AS stores the configuration settings. 

9. The NAF/PNM AS sends the PN-configuration response to the UE. 
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5.4 PN-deconfiguration 

5.4.1 General 

The PN-deconfiguration procedure enables the PN-user to deconfigure the defauh UE of a PN. Corresponding to the 
configuration procedure described in subclause 5.3, the PN-deconfiguration can be done in three levels in IM CN 
subsystem and two levels in CS domain. 

The following subclauses describe the PN-deconfiguration procedure in the IM CN subsystem. 

5.4.2 PN-deconfiguration procedure in tine IM CN subsystem 



UE 



HSS 



NAF/PNM 
AS 



1. PN-deconfiguration Request 



2. PN 

Authentication 

and Authorization 



3. Service Subscription Unsubscribe Request 



4. Service Subscription Unsubscribe Response 



5. Remove the 

Configuration 

Settings 



6. PN-deconfiguration Response 



7. Status 



Figure 5.4.2-1: Successful PN-deconfiguration procedure in the IIV! CN Subsystem 

The signalling flow in figure 5.4.2-1 describes the signal flow between UE and NAF/PNM AS when the UE wants to 
deconfigure the PN. The messaging shall only take place after a successful bootstrapping procedure (as described in 
3GPP TS 33.220 [11]) in which case the bootstrapped security association has been established before Step 1. 

1 . In order to remove its configuration settings for the PN UE redirection applications from the PN, a UE sends a 
Deconfiguration request message to the PNM AS containing the public user identity/identities of the UEs to be 
deconfigured. Additionally, other relevant parameters for executing the PN UE redirection application such as 
the configuration level and the priority value can be included. 

2. Upon receiving the PN-deconfiguration request, the NAF/PNM AS authenticates the PN-deconfiguration 
Request according to the 3GPP TS 33.222 [9]. After a successful authentication, the NAF inserts the private user 
identity of the UE and forwards it to the PNM AS. The PNM AS authorizes the PN-deconfiguration request by 
comparing the public user identity with those ones that are registered in the PN by means of the PN-registration 
procedure. 

3. The PNM AS sends the Unsubscribe request to the HSS. 

4. The HSS sends the Unsubscribe response to the PNM AS. 

5. The PNM AS removes the stored configuration setting. 

6. The PNM AS sends the PN-deconfiguration response to the UE. 
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7. If the UE ties to this specific public user identity registered as the only default UE, then the NAF/PNM AS sends 
the Status message request to these UEs of the PN to inform this change. 

5.5 PN-query 

5.5.1 General 

Figure 5.5.2-1 shows a successful PN-query procedure that is used by the PN-users to enquiry their PN settings 
information which is stored in the PNM AS after performing the PN-registration and PN-configuration procedures. 

5.5.2 PN query procedure 

The PN setting information belonging to a PN-user can be categorized into: 
information about the registered public user identities, 

settings for PN UE redirection, such as the default UEs, service level settings and redirection priority, 
settings for the PN access control, such as a PN access control list. 



UE 



HSS 



1. PN-query Request- 



-3. PN-query Response- 



NAF/PNM AS 



2. PN Authentication 
and Autiiorization 



Figure 5.5.2-1 : Successful PN query procedure in the IIUI CN subsystem 

The signalling flow in figure 5.5.2-1 describes the signal flow between UE and NAF/PNM AS when the UE wants to 
query the PN settings. The procedure shall only take place after a successful bootstrapping procedure (as described in 
3GPP TS 33.220 [11]) in which case the bootstrapped security association has been established before Step 1. 

1 . UE sends a PNquery request to the NAF/PNM AS in order to obtain the PN setting information classified above 
for the PNM applications by including the public user identity/identities of the UEs. 

2. Upon receiving the PN-query request, the NAF/PNM AS authenticates the PN-query request according to the 
3GPP TS 33.222 [9]. After a successful authentication, the NAF/PNM AS inserts the private user identity 
associated with the public user identity/identities of the UE and forwards the message to the NAF/PNM AS. The 
NAF/PNM AS authorizes the PN-query request by comparing the public user identity with those ones that are 
registered in the PN by means of the PN-registration procedure. 

3. The NAF/PNM AS sends the PNquery response message to the UE containing the PN settings information for 
the PNM applications as asked by the UE. 
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6 Procedures and information flows for PN UE 

redirection 

6.1 Procedures and information flows in the IP CN subsystem 

6.1.1 General 

One of the functionalities enabled by the PNM AS in the IM CN subsystem is called PNUE redirection that redirects 
sessions destined for any UEs of a PN to the default UE of the same PN as described in 3GPP TS 22.259 [1]. The PN 
UE redirection applies only to the initial request for a UE-terminating call. The procedures for supporting the PN UE 
redirection in the IM CN subsystem take advantage of the interface between an S-CSCF and an AS in the IM CN 
subsystem described in 3GPP TS 23.002 [2] and the procedures described in 3GPP TS 23.218 [3]. 

When receiving an initial request for a UE-terminating call, the S-CSCF performs the procedure defined in 
3GPP TS 23.218 [3] to route the initial request for the UE-terminating call to the PNM AS based on matching of initial 
filter criteria before performing any other routing procedures to the terminating UE. The PNM AS then executes the 
redirection of the initial request to the default UE of the PN based on the PN-user"s PN configuration as described in 
clause 6. The redirection of the initial request for the UE-terminating call can be executed either on an IP multimedia 
application basis or on the media component(s) of an IP multimedia application basis supported by the terminating UE 
capabilities and the PN-user subscriptions. 

If the PN-user configured a UE list of different priorities for the PN UE redirection, the PNM AS shall execute the 
session redirection for a particular UE based on the configuration in a decreasing order of the priority. If the session 
redirection for a UE of a higher priority fails, the PNM AS shall perform the PNM session redirection for the other UE 
of the next lower priority. 

6.1 .2 Procedures and information flows for PN UE redirection in the IM 
CN subsystem 

Figure 6.1.2-1 describes the procedures and information flows for handling the PN UE redirection in the IM CN 
subsystem. Without loss of generality, it is assumed for figure 6.2.1-1 that a PN-user"s PN consists of two UEs, i.e., the 
UE-1 and the UE-2. The UE-2 is the default UE according to PN-user"s PN configuration as described in Clause 6. 
Furthermore, it is assumed that the two UEs have different public user identities. 
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Figure 6.1.2-1 : Initial request to UE-1 and redirected to UE-2 by the PNM AS in the IM CN subsystem 

1. An initial request to the UE-1 containing the Request-URI of the UE-1 public user identity arrives at the S-CSCF 

#1. 

2. The S-CSCF #1 determines that the initial request is for a UE-terminated case, invokes the termination service 
control logic required for the UE-1 and evaluates the initial filter criteria, which results in re-routing the initial 
request to the PNM AS. 

3. As a result of the termination service control logic invocation for the UE-1, the S-CSCF #1 forwards the initial 
request to the PNM AS. 

4. The PNM AS executes the PN UE redirection control logic based on the PN-user"s PN configurations as 
described in clause 6. The PNM AS decides to redirect the initial request to the default UE of the PN, i.e., to the 
UE-2. 

5. As a result of the PN UE redirection control logic execution, the PNM AS sends the redirected initial request 
containing the Request-URI of the UE-2 public user identity to the S-CSCF #1. 

6. The S-CSCF #1 treats the redirected initial request as a UE-originated case, and forwards the redirected initial 
request to the S-CSCF #2. The S-CSCF #1 and the S-CSCF #2 can be the same entity. 

7. The S-CSCF #2 treats the redirected initial request as a UE-terminated case, invokes the termination service 
control logic required for the UE-2 and evaluates the initial filter criteria, which may results in re-routing the 
redirected initial request to the other ASs. 

8-10. The S-CSCF #2 forwards the redirected request to the PNM AS as the result of the termination service 
control logic for the UE-2. The PNM AS executes the PN UE redirection control logic and decides to forward 
the request as the UE-2 is the default UE of the PN. 

11. The S-CSCF#2 continues the redirected initial request based on the standard call setup procedures as described 
in 3GPP TS 23.228 [4]. 
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Figure 6.1.2-2 describes the procedures and information flows for handling the PN UE redirection in the IM CN 
subsystem when the default UE (in this example the UE-2) in the PN shares the same public user identity with the UE- 
1. 

NOTE: It" s assumed that the UE-2 can support GRUU. 
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Figure 6.1.2-2: Initial request to UE-1 and redirected to UE-2 by the PNM AS in the IM CN subsystem 
when the UE-2 shares the same public user identity with the UE-1 

1. An initial request to the UE-1 containing the Request-URI of the UE-1 public user identity arrives at the S- 
CSCF. 

2. The S-CSCF determines that the initial request is for a UE-terminated case, invokes the termination service 
control logic required for the UE-1 and evaluates the initial filter criteria, which results in re-routing the initial 
request to the PNM AS. 

3. As a result of the termination service control logic invocation for the UE-1, the S-CSCF forwards the initial 
request to the PNM AS. 

4. The PNM AS executes the PNM redirection service control logic based on the User"s PN configurations as 
described in clause 6. The PNM AS decides to redirect the initial request to the default UE of the PN, i.e., to the 
UE-2. 

5. As a result of the PNM redirection service logic execution, the PNM AS sends the redirected initial request 
containing the Request-URI which is set to the GRUU of the UE-2 to the S-CSCF. 

6. The S-CSCF continues the redirected initial request procedure based on the standard call setup procedures as 
described in 3GPP TS 23.228 [4]. 

Figure 6.1.2-3 describes the procedures and information flows for handling the PN UE redirection in the IM CN 
subsystem when the default UE (in this example the UE-2) in the PN cannot setup the session. Consequently, the PNM 
AS performs the PNM session redirection for the other UE of the next lower priority (in this example the UE-3). 
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Figure 6.1.2-3: Initial request to UE-1 and redirected to UE-3 by the PNM AS in the IM CN subsystem 

when the initial request to UE-2 fails 

1. An initial request to the UE-1 containing the Request-URI of the UE-1 public user identity arrives at the S-CSCF 
#1. 

2. The S-CSCF #1 determines that the initial request is for a UE-terminated case, invokes the termination service 
control logic required for the UE-1 and evaluates the initial filter criteria, which results in re-routing the initial 
request to the PNM AS. 

3. As a result of the termination service control logic invocation for the UE-1, the S-CSCF #1 forwards the initial 
request to the PNM AS. 

4. The PNM AS executes the PN UE redirection control logic based on the PN-user"s PN configurations as 
described in clause 6. The PNM AS decides to redirect the initial request to the default UE of the PN, i.e., to the 
UE-2. 

5. As a result of the PN UE redirection control logic execution, the PNM AS sends the redirected initial request 
containing the Request-URI of the UE-2 public user identity to the S-CSCF #1. 

6. The S-CSCF #1 treats the redirected initial request as a UE-originated case, and forwards the redirected initial 
request to the S-CSCF #2. The S-CSCF #1 and the S-CSCF #2 can be the same entity. 
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7. The S-CSCF #2 treats the redirected initial request as a UE-terminated case, invokes the termination service 
control logic required for the UE-2 and evaluates the initial filter criteria, which may results in re-routing the 
redirected initial request to the other ASs. 

8-10. The S-CSCF #2 forwards the redirected request to the PNM AS as the result of the termination service 
control logic for the UE-2. The PNM AS executes the FN UE redirection control logic and decides to forward 
the request as the UE-2 is the default UE of the FN. 

11. The S-CSCF#2 continues the redirected initial request which is forwarded to UE-2. 

12-13. UE-2 cannot setup the session and returns an error response back to FNM AS. 

14. The FNM AS executes the FN UE redirection control logic for the other UE of the next lower priority which in 
this example is UE-3. 

15-16. As a result of the FN UE redirection control logic execution, the FNM AS forwards the redirected initial 
request containing the Request- URI of the UE-3 public user identity to the UE-3. 

6.2 Procedures and information flows in the CS domain 

6.2.1 General 

Similar to the functionality described in the subclause 6.1.1, the gsmSCF (CAMEL service for FNM) can redirect calls 
destined for any UEs of a FN in the CS domain to the default UE of the same FN. The procedures for supporting the 
FNM call redirection in the CS domain takes advantage of the interface between a GMSC and a gsmSCF in the CS 
domain described in 3GFF TS 23.078 [8] and the procedures described in 3GFF TS 23.018 [10]. 

When receiving a call request for a UE in the FN, the GMSC performs the procedure defined in 3GFF TS 23.078 [8] to 
route the request to the gsmSCF (CAMEL service for FNM) based on the T_CSI configured to the UE before 
performing any other routing procedures to the terminating UE. The gsmSCF (CAMEL service for FNM) then executes 
the redirection of the request based on the FN-user"s FN configuration as described in clause 6. 

If the FN-user configured a UE list of different priorities for the FNM call redirection, the gsmSCF (CAMEL service 
for FNM) shall execute the call redirection for a particular UE based on the configuration in a decreasing order of the 
priority. If the call redirection for a UE of a higher priority fails, the gsmSCF (CAMEL service for FNM) shall perform 
the FNM call redirection for the other UE of the next lower priority. 

6.2.2 Procedures and information flows for PN UE redirection in the CS 
domain 

Figure 6.2.2-1 describes the procedures and information flows for handling the FNM call redirection in the CS domain. 
Without loss of generality, it is assumed for figure 6.2.2-1 that a FN-user"s FN consists of two UEs, i.e., the UE-1 and 
the UE-2. The UE-2 is the default UE according to FN-user"s FN configuration as described in clause 6. 
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Figure 6.2.2-1 : Initial request to UE-1 and redirected to UE-2 by the gsmSCF (CAMEL service for PNM) 

in the CS domain 

1. A call request to the UE-1 containing the MSISDN of the UE-1 as the called party number arrives at the GMSC 
#1. 

2. On receipt of the incoming call request, the GMSC#1 queries the HSS for routing information. 

3. The HSS provides information including the T-CSI information element that contains information configured for 
the PNM subscriber, identifying the subscriber as having terminating CAMEL services. 

4. The HSS returns the T-CSI information element to the GMSC#1 in response to the query for routing information 
(SRI). 

5. The GMSC#1 triggers a CAMEL activity which results in sending a CAMEL IDP message to the GSM Service 
Control Function (gsmSCF). 

6. The gsmSCF (CAMEL service for PNM) executes the PN UE redirection control logic based on the PN-user"s 
PN configurations as described in clause 6. The gsmSCF (CAMEL service for PNM) decides to redirect the call 
request to the default UE of the PN, i.e., to the UE-2. 

7. As a result of the PN UE redirection control logic execution, the gsmSCF (CAMEL service for PNM) to respond 
to the CAMEL IDP message with a CAMEL CONNECT message containing the MSISDN of the UE-2 as the 
called party number. 

8. The GMSC#1 initiates the CS call towards the GMSC#2 by sending an Initial Setup Message (e.g. ISUP lAM, 
BICC lAM, and SIP-I Invite). 
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9-13. The GMSC#2 queries the HSS for routing information and triggers a CAMEL activity to the gsmSCF. The 
gsmSCF executed the PNM redirection service control logic and decides to forward the request as the UE-2 is 
the default UE of the PN, so it responds with a CMAEL CONTINUE message to the GMSC#2. 

14. The GMSC#2 continues the redirected call request based on the standard call setup procedures as described in 

3GPPTS 23.018 [10]. 

Figure 6.2.2-2 describes the procedures and information flows for handling the PN UE redirection in the CS domain 
when the default UE (in this example the UE-2) in the PN cannot setup the session. Consequently, the gsmSCF 
performs the PNM session redirection for the other UE of the next lower priority (in this example the UE-3). 
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Figure 6.2.2-2: Initial request to UE-1 and redirected to UE-3 by the gsmSCF (CAMEL service for PNM) 

in the CS domain when the initial request to UE-2 fails 

1. A call request to the UE-1 containing the MSISDN of the UE-1 as the called party number arrives at the GMSC 
#1. 

2. On receipt of the incoming call request, the GMSC#1 queries the HSS for routing information. 

3. The HSS provides information including the T-CSI information element that contains information configured for 
the PNM subscriber, identifying the subscriber as having terminating CAMEL services. 
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4. The HSS returns the T-CSI information element to the GMSC#1 in response to the query for routing information 
(SRI). 

5. The GMSC#1 triggers a CAMEL activity which results in sending a CAMEL IDP message to the GSM Service 
Control Function (gsmSCF). 

6. The gsmSCF (CAMEL service for PNM) executes the PN UE redirection control logic based on the PN-user"s 
PN configurations as described in clause 6. The gsmSCF (CAMEL service for PNM) decides to redirect the call 
request to the default UE of the PN, i.e., to the UE-2. 

7. As a result of the PN UE redirection control logic execution, the gsmSCF (CAMEL service for PNM) to respond 
to the CAMEL IDP message with a CAMEL CONNECT message containing the MSISDN of the UE-2 as the 
called party number. 

8. The GMSC#1 initiates the CS call towards the GMSC#2 by sending an Initial Setup Message (e.g. ISUP lAM, 
BICC lAM, and SIP-I Invite). 

9-13. The GMSC#2 queries the HSS for routing information and triggers a CAMEL activity to the gsmSCF. The 
gsmSCF executed the PNM redirection service control logic and decides to forward the request as the UE-2 is 
the default UE of the PN, so it responds with a CMAEL CONTINUE message to the GMSC#2. 

14. The GMSC#2 continues the redirected call request based on the standard call setup procedures as described in 
3GPPTS 23.018 [10]. 

15. UE-2 cannot setup the session and generates an error response. 

16. GMSC#2 sends the EventReportBCSM message to the gsmSCF. 

17. The gsmSCF executes the PN UE redirection control logic for the other UE of the next lower priority which in 
this example is UE-3. 

18-19. As a result of the PN UE redirection control logic execution, the gsmSCF forwards the redirected initial 
request containing the MSISDN of the UE-3 as the called party number to the UE-3. 

6.3 Procedures and information flows in the domain 
interworking 

6.3.1 General 

After the PNM AS executes the redirection of the initial request based on the PN-user"s PN configuration, the initial 
request could be routed to different domain, i.e. from IM CN subsystem to CS domain or from CS domain to IM CN 

subsystem. 

The procedures for supporting the interworking between IM CN subsystem and CS domain in the PNM session 
redirection take advantage of the procedures specified in 3GPP TS 23.228 [4]. 

NOTE: If the UE-2 is attached both in the CS domain and the IM CN subsystem, how the PNM AS selects the 
particular domain for the PN UE redirection is out of the scope of this document. 

6.3.2 Procedures and information flows for PN UE redirection from IIVI CN 
subsystem to CS domain 

Figure 6.3.2-1 describes the procedures and information flows for handling the PNM Session redirection from IM CN 
subsystem to CS domain. Without loss of generality, it is assumed for figure 6.3.2-1 that a PN-user"s PN consists of two 
UEs, i.e., the UE-1 and UE-2 and the UE-2 attached in CS domain doesn"t have the subscription to IMS is the default 
UE according to PN-user"s PN configuration as described in clause 6. 
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Figure 6.3.2-1 : Initial request in IM CN subsystem and redirected to UE-2 in CS domain by the PNM 

AS 

1 . An initial request destined to the UE-1 containing the Request-URI of the UE-1 public user identity arrives at the 
S-CSCF. 

2. The S-CSCF determines that the initial request if for a UE-terminated case, invokes the termination service 
control logic required for the UE-1 and evaluates the initial filter criteria, which results in re-routing the initial 
request to the PNM AS. 

3. As a result of the termination service control logic invocation for the UE-1, the S-CSCF forwards the initial 
request to the PNM AS. 

4. The PNM AS executes the PN UE redirection control logic based on the PN-user"s PN configurations as 

described in clause 6. The PNM AS decides to redirect the initial request to the default UE of the PN, i.e., to the 
UE-2 which in this example can be found in the CS domain only. 

5. As a result of the PN UE redirection control logic execution, the PNM AS sends the redirected initial request 
containing the Request-URI of the UE-2 public user identity to the S-CSCF. 

6. The S-CSCF treats the redirected request as a UE-originated case and performs the domain transit procedure 
specified in 3GPP TS 23.228 [4]. Eventually, the session initiation arrives to an MGCF. 

7. The MGCF sends an 1AM message containing the MSISDN of the UE-2 as the called party number towards 
GMSC. 

8. The GMSC continues the redirected call request based on the standard call setup procedures as described in 
3GPPTS 23.018 [10]. 

6.3.3 Procedures and information flows for PN UE redirection from CS 
domain to IM CN subsystem 

Figure 6.3.3-1 describes the procedures and information flows for handling the PN UE redirection from CS domain to 
IM CN subsystem. Without loss of generality, it is assumed for figure 6.3.3-1 that a PN-user"s PN consists of two UEs, 
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i.e., the UE-1 and UE-2 and the UE-2 registered only in IM CN subsystem is the default UE according to PN-user"s PN 
configuration as described in clause 6. 
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Figure 6.3.3-1 : Initial request in CS domain and redirected to UE-2 in IM CN subsystem by the 

gsmSCF 

1. A call request to the UE-1 containing the MSISDN of the UE-1 as the called party number arrives at the GMSC. 

2. On receipt of the incoming call request, the GMSC queries the HSS for routing information. 

3. The HSS returns the T-CSI information element that contains information configured for the PNM subscriber to 
the GMSC#1 in response to the query for routing information (SRI). 

4. The GMSC triggers a CAMEL activity which results in sending a CAMEL IDP message to the gsmSCF 
(CAMEL service for PNM). 

5. The gsmSCF (CAMEL service for PNM) executes the PN UE redirection control logic based on the PN-user"s 
PN configurations as described in clause 6. The gsmSCF (CAMEL service for PNM) decides to redirect the call 
request to the default UE of the PN, i.e., to the UE-2 which in this example can be found in IM CN subsystem 
only. 

6. As a result of the PN UE redirection control logic execution, the gsmSCF (CAMEL service for PNM) responds 
to the CAMEL IDP message with a CAMEL CONNECT message containing the MSISDN of the UE-2 as the 
called party number. 

7. The GMSC initiates the call to the MGCF with an lAM message containing the MSISDN of UE-2 as the called 
party number. 

8. The MGCF initiates a SIP INVITE request with the request URI of UE-2 public user identity towards the S- 
CSCF. 

9. The S-CSCF continues the redirected initial request based on the standard call setup procedures as described in 
3GPPTS 23.228 [4]. 
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7 



Procedures and information flows for PN access 
control 



7.1 



General 



Upon receiving a UE-terminating initial request, the PNM AS shall first check whether the request originates from 
another PN UE within the same PN as the terminating PN UE and if so the PNM AS shall allow the session 
establishment to continue. If the request does not originate from another PN UE within the same PN as the terminating 
PN UE the PNM AS shall invoke the PN access control application if it is enabled. If no access control list exists for the 
terminating UE, and if the PNM AS does not invoke the PN UE redirection for the terminating UE, the PNM AS sends 
the initial request to the terminating UE (i.e., a UE of a PN). Otherwise, the PNM AS verifies whether the originating 
UE of the initial request is a valid entry contained in the PN access control list for the terminating UE, before it initiates 
session towards the terminating UE. With a successful verification, the PNM AS sends the initial request to the 
terminating UE. With an unsuccessful verification, if the terminating UE is not a controllee UE, then the PNM AS 
rejects the initial request. If the terminating UE is a controllee UE, the PNM AS queries the controller UE whether the 
session to the controllee UE is allowed to be established. If it is allowed, and if the PNM AS does not invoke the PN UE 
redirection for the terminating UE, the PNM AS sends the initial request to the controllee UE. Otherwise, the PNM AS 
rejects the initial request. Figure 7.1-1 gives a snapshot of the scenario. 
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Controlled UE(if 
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(UE la) 



Controllee 
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Figure 7.1-1 : Overview of privacy based access control Procedures and Information Flows 

NOTE: The Solid line refers to access control handled by the PNM AS itself, since the identity of the originating 
caller is present in the access control list of the PNM AS. The dashed line refers to access control handled 
by the controller UE when the identity of the caller is not present in the access control list of the PNM 
AS. 

The procedures at the PNM AS to accomplish the PN access control execution are described with the assistance of 
figure 7.1-2. 

When the PNM AS receives a SIP initial request and its PN access control logic is switched-on, if the Request URI of 
the initial request identifies with the controllee UE(s), the PNM AS shall further decide whether the Request URI 
uniquely identify a controllee UE within a PN: 

1) if a controllee UE is uniquely identifiable, the PNM AS shall check whether the Caller is in the PN access 
control list; 

a) if the Caller is in the PN access control list, the PNM AS shall send the initial request to the controllee UE; 

b) if the Caller is not in the PN access control list. 
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i) if there is no need to interrogate the controller UE, the PNM AS shall reject the initial request; 

ii) if there is a need to interrogate the controller UE, the PNM AS shall interrogate the controller UE and 
handle the initial request message based on the interrogation results from the PN-user. 

Editor's note: The use of GRUU as described in 3GPP TS 23.228 [4J can assist the PNM AS with uniquely 
identifying a controllee UE. 

2) if a controllee UE is not uniquely identifiable, the PNM AS shall perform the PN access control without 
invoking the controller UE (i.e., without any PN-user interaction) and check whether the Caller is in the PN 
access control list; 

a) if the Caller is in the PN access control list, the PNM AS shall send the initial request back to the S-CSCF 
(see 3GPPTS 23.228 [4]); 

b) if the Caller is not in the PN access control list, the PNM AS shall reject the initial request. 




Reject the initial 
request 



Interrogating the 
controiier UE 



Figure 7.1-2: PN access control execution flow at the PNM AS (AC and ACL stand for Access Control 

and Access Control List, respectively) 
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7.2 PN access control procedures in the IM CN subsystem 

Without lack of generality, the following assumptions have been made with respect to the terminals and the network. 

<Assumptions related to identities of UEs> 

PN-user 1 has two UEs - UE la & UE lb in the PN, containing identities userl_publicl @homel.net and 
userl_public2@homel.net respectively, and having a subscription with the home network providing PNM 
service. 

UE lb is configured as controllee UE and UE la as controller UE by the PN-user 1. 

The originating UE which initiates the request may belong to the same/different network where the PNM AS is 
located. The originating UE of the initial request needs not be aware of the setting of the access control done by 
PN-user 1 . 

PN-user Ihas configured UE2 with user2 public@home2.net as the only entry in the access control list related to 
the controllee UE in this example. When the PNM AS receives initial requests not coming from UE2, the PNM 
AS can query the controller UE and the continuation of the initial request depends on the outcome of the query. 

The following table summarizes the above assumptions. 

Table 1 : Example of a simple access control table PN 



PN Of user 


controllee UE 


controller UE 


Access List entries 


(UEIa) 

user1 public1@home1.net 


No 


N/A 


N/A 


(UEIb) 

userl Dublic2(3)home1.net 


Yes 


UEIa 


(UE2) 

user2 Dublic(S>home2.net 



<Network assumptions> 

PN-user"s home network provides PN access control, which allows PN-users to configure identities (e.g., a SIP 
URI) which are permitted to initiate sessions to the UE of the PN. 

This service is hosted by the PNM Server which is a SIP application server, serving scscf#l. 

For simple illustration, in this example, both identities of the PN are shown to be registered with the same S- 
CSCF (S-CSCF#1) to improve efficiency in signalling, which might be the case in most implementations. 

The PNM AS stores access control lists of controllee UE and the controller UE can process access control 
requests during dynamic procedures. 

UE 3 sends an initial request to UE lb ( userl public2@homel.net) . But, UE 3 hasn"t been configured by the PN-user 
in the access control list. Therefore, the PN MAS queries the controller UE (i.e., UE la) about the information as to 
how to process this initial request. 



ETSI 



30 



ETSI TS 123 259 V8.2.0 (2009-01) 



7.3 PN access control procedure in the IM CN subsystem 

7.3.1 General 

An inherent problem in the Access control list case is the need for the PN-user to configure each originating UE that the 
PN-user feels appropriate. This may not be a scalable solution where tens of UEs may try to access the controllee UE. 
In order to solve this problem, the PN-user may configure a controller UE, after processing of this decision normal 
session initiation procedures may be continued. Once the controller UE has been chosen, to handle all session initiation 
requests from UEs whose identities are not configured in the access control list, a query can be directed to the particular 
controller UE. 

The controller UE in turn is capable of checking the access control information of this query. Options may be given to 
the PN-user to either accept the call himself, or answer the query by allowing the call to go through to the intended 
destination (controllee UE) or deny the call. In addition the user may be given an option of saving this policy for future 
call requests by the same source. Once the user makes the decision, a response message carrying this information may 
be sent directing the session back to the original destination. 

The PNM AS receives the response message from the S-CSCF. If the decision of the PN-user was to allow the call, it 
sends the original initial request message. If required to save (based on user response) it saves the settings for the 
originating UE in the access control list 

7.3.2 PN access control based on query logic in the IM CN subsystem 

In figure 7.3.2-1 it is assumed that the originating UE (i.e., UE 3) is not configured in the access control list of the 
controllee UE (i.e., UE lb). When the PNM AS receives an Initial Request from S-CSCF# 1, the PNM AS verifies 
whether UE 3 matches an entry in the access control list of UE lb. In this case, the PNM AS sends a Query to the 
controller UEla to determine the handling. 



Originating Network | Home Network 

UE 3 S-CSCF#1 

1. initial request 



PNM AS 



Terminating Home Network 
UE 1a UE1b 



2. Service Controi 



3. initial request 



4. Logic 
mode pr 



Privacy 
jcessing 



5. Query 



8. Query Response 



9. Query Response 



10. Logic 
mode pr 



11. initial request 



6. Query 



7. Privaq decision 
proa ssing 



Privacy 
jcessing 



12. initial request 



Figure 7.3.2-1 : High level sequence of PN access control 

1. UE 3 sends an Initial Request towards UE lb. 

2. S-CSCF#1 invokes whatever service logic is appropriate for this session setup attempt. 
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3. In this case, the initial fiher criterion is triggered and the initial request message is forwarded to the 
corresponding PNM AS. 

4. The PNM AS receives the initial request and the privacy mode processing is executed. 

The PNM AS extracts the source and destination addresses. It confirms that the destination UE is a controUee 
UE. Using this as a key, it searches its database for the particular PN to find if UE 3 is configured in the access 
control list as allowed to initiate sessions with UE lb. 

If the originating UE has been configured in the access control list, normal processing is continued. If there is no 
information regarding the address of the originating UE, the PNM AS may then send a Query to the controller 
UE, i.e., UE la in this example, containing the access request of UE lb by UE 3. This Query can be processed 
byUEla. 

5. As a result of Step 4, the PNM AS queries the controller UE about the information of how to precede with the 
Initial Request by sending a Query to S-CSCF#1. 

6. S-CSCF#1 validates the service profile, and invokes any termination service logic required for UE la and 
forwards the Query to UE 1 a. 

7. In the privacy decision processing, the information contained in the Query is indicated to the PN-user. 
(Example: UE 3 calling UE lb, 1: Allow, 2: Deny 3: Allow and save policy 4: Deny and save policy 5: Accept). 
The PN-user may then allow/disallow and possibly save this option for future calls. This information is sent in 
the Query Response. 

8. The decision of the user is sent in the Query Response. 

9. The S-CSCF#1 forwards the Query Response towards the PNM AS. 

10. In the privacy response processing step, the PNM AS determines the action directed by the user. If the PN-user 
has allowed the Initial Request to pass to the UE lb, the Initial Request is sent to UE lb. 

NOTE 1 : If the user has chosen to save the policy, the policy is stored in the access control list of the controllee UE 
using the PN-configuration procedure. 

1 1. The PNM AS sends the original Initial Request to the S-CSCF#1 

12. The S-CSCF#1 forwards the initial request message to UE lb. 

NOTE 2: Interaction with other services; The privacy service is to authorize the call where the authorization apart 
from normal authorization procedures involved in the network, requires real time consent from the user. 
All other supplementary features or other services may follow once this authorization is received. 

7.3.3 PN access control based on access control lists 

In figure 7.3.3-1 it is assumed that the originating UE (i.e., UE 2) is configured in the access control list of the 
controllee UE (i.e., UE lb). When the PNM AS receives an Initial Request from S-CSCF# 1, the PNM AS verifies 
whether UE 2 matches an entry in the access control list of UE lb. In this case, the PNM AS sends the Initial Request 

message to UE lb. 
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Figure 7.3.3-1 : PN access control in case of PNIV! AS alone 

1. S-CSCF#1 receives an Initial Request from UE 2 to UE lb. 

2. S-CSCF#1 invokes the termination service control logic required for the UE lb and evaluates the initial filter 
criteria. 

3. S-CSCF#1 forwards the Initial Request to the PNM AS as a result of executing the initial filter criteria. 

4. In the privacy mode processing step, the PNM AS extracts the source and destination addresses. It confirms that 
UE lb is a controllee UE. Using this as a key, it searches its database for the PN of UE lb to find if UE 2 is 
configured in the access control list. In this case, it is assumed that UE 2 is allowed to initiate sessions with UE 
lb. 

5. The PNM AS sends the Initial Request message to the S-CSCF#1. 

6. The S-CSCF#1 routes the Initial Request message to the UE lb. 
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7.4 PN access control procedure in the CS domain 



7.4.1 



General 



PN access control deals with a user having access control over his Personal Network, wherein he may restrict access to 
his UEs. These UEs of the PN, over which access control has been enabled, are configured as controllee UE. To initiate 
sessions with these controllee UEs, the originating UEs need to be configured by the PN-user in a PN access control 
list. For information regarding the originating UEs that are configured in the PN access control list, which is the case in 
majority of the scenarios, the user nominates a controller UE to handle the access control. In this case, the network 
queries the user whether the call to the controllee UE may be allowed to go through. If the user allows it, the network 
allows the call to go through. 

7.4.2 PN access control procedure (When the caller is not in the PN 
access control list) 

If the caller is not in the PN access control list the gsmSCF interacts with the controller UE in order to route the call to 
the Controllee UE. Figure 7.4.2-1 shows the implementation of access control procedure in CS domain when the caller 
is not in PN access control list. 
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Figure 7.4.2-1 : PN access control Procedure in CS domain 

1 . A call request to the UE located in PN containing the MSISDN of the UE arrives at the GMSC. 

2. GMSC queries the HSS for routing Information by sending MAP SRI. 

3. HSS checks the subscription information for the called party. Further the HSS provides the information for the 
PNM subscriber including the T-CSI. The HSS returns the T-CSI to the GMSC in the response (MAP-SRI- 
ACK) 
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4. The GMSC triggers a CAMEL activity which results in sending a CAMEL IDP to gsmSCF. 

5-7. The gsmSCF executes the PN access control logic and will check with the controller UE about the 

acceptability of call request by sending USSD request message to the controller UE via HSS and MSC/VLR. 

NOTE: This USSD message includes the call Information such as the public user Identity of caller and 

terminating UE. 

8. The controller UE displays the text provided and awaits user input. The user decides whether the call request is 
allowed or not and accordingly the controller UE will send the USSD response message to MSC/VLR. 

9-10. The MSC/VLR will forward this USSD response message to gsmSCF via HSS. 

1 1 . The gsmSCF will continue the call or release the call by sending the CAMEL continue message/release call 
message to the GMSC according to the controller UE"s response Based on the decision by the controller UE the 
call will established or released. 

Figure 7.4.2-2 provides a solution for the time delay problem which can occur during interaction between the network 
and the controller UE. 
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Figure 7.4.2-2: PN access control procedure in CS domain with delay handling. 

1 . A call request to a UE containing the MSISDN of the UE arrives at the GMSC. 

2. The GMSC queries the HSS for routing Information by sending MAP SRI. 

3-4 The HSS checks the subscription information for the called party. Further the HSS provides the information for 
the PNM subscriber including the T-CSI. The HSS returns the T-CSI to the GMSC in the response. 

5. The GMSC triggers a CAMEL activity which results in sending a CAMEL IDP to gsmSCF. 
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6. & 8-10 The gsmSCF executes the PN access control logic and will check with the controller UE about the 

acceptability of the call request by sending USSD request message to the controller UE via HSS and MSC/VLR. 

NOTE: This USSD message includes the call Information such as the public user Identity of the originating and 
the terminating UE. 

7. The gmsSCF will start the Timer. 

1 1 . Supervision of the started timer by the gsmSCF. 

12-13. If the time out occurs because no response from the controller UE, the gsmSCF will send the Play 
Announcement message to the GMSC and the GMSC will send an early ACM to the originating UE. 

NOTE: Step 12-13 can be skipped if the controller UE responds before timer out occurs. No ACM will be send. 

14. The controller UE displays the text provided and awaits user input. The user decides whether the call request is 
allowed or not and accordingly the controller UE will send the USSD response message to MSC/VLR. 

15-16. The MSCA'LR will forward this USSD response message to the gsmSCF via the HSS. 

17. The gsmSCF will send a message to GMSC to stop playing the announcement if it is generated. The gsmSCF 
will continue the call or release the call by sending the CAMEL continue message/release call message to the 
GMSC according to the controller UE"s response. 

7.4.3 PN access control procedure in CS domain (Winen tine caller is in 
the PN access control list) 

Figure 7.4.3-1 shows the PN access control procedure when the caller is in PN access control list. 
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Figure 7.4.3-1 PN access control procedure in the CS domain (Caller is in the PN access control list) 

1 . A call request to the PN UE containing the MSISDN of the UE arrives at the GMSC. 

2. The GMSC queries the HSS for routing Information by sending MAP SRI. 

3-4. The HSS checks the subscription information for the called party. Further the HSS provides the information 
for the PNM subscriber including the T-CSI. The HSS returns the T-CSI to the GMSC in the response 

5. The GMSC triggers a CAMEL activity which results in sending a CAMEL IDP to gsmSCF. 

6. The gsmSCF executes the PN access control logic for access control procedure. The calling party is part of the 
access control list for this PN. 

7. Based on the positive result, the gsmSCF send the CAMEL CONTINUE message to GMSC to continue the call. 

8. The GMSC queries the HSS for routing Information by sending MAP SRI with "Suppress T-CSI" set. 

9. The HSS returns the retrieved MSRN to the GMSC in response by sending MAP SRI_ACK. 

10. The GMSC generates a call request message containing MSRN and sends it to MSC/VLR. 
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